Multimedia Broadcast Multicast Service (MBMS) is supposed to deliver a variety of services that can cope with different levels of transport Block Error Rates (BLER) on the application layer. Example services are download services, audio/video streaming, and messaging. Some services, like download services, tolerate relatively high BLER, in the order of 10% or even larger, because of error correction coding on higher communication layers.
For example, some download services require a BLER of 20 to 40%, audio/video streaming usually requires a BLER of 0.1 to 1%, and messaging also requires typically a BLER of 0.1 to 1%, i.e. these BLERs are typically assumed to be acceptable for the respective services. In live-critical applications, e.g. emergency or accident warnings, the BLER of messaging services has to be very low, possibly well below 0.1%.
In the context of MBMS, one known approach is to map services tolerating different transport BLERs to different Multicast Channels (MCHs). That is, service specific BLER requirements can be supported by configuring multiple MCHs with different Modulation and Coding Schemes (MCSs) per MBMS Single Frequency Network (MBSFN) area and mapping each service to the appropriate MCH, i.e. multiple MCHs in an MBSFN area are configured with different MCSs.
In accordance with this commonly known approach, different services tolerating different BLERs are mapped to different MCHs. Each MCH can then be configured for the desired BLER or equivalently a required Quality of Service (QoS) by selecting an appropriate MCS.
When multiple MCHs are used within an MBSFN area, MBMS services can be transmitted differently. Different QoS (or MCS) for different logical channels can be provided by using multiple MCHs and the QoS (or MCS) for all logical channels on one MCH can be same. In other words, the same type of MBMS services can be multiplexed into the same MCH while other types of services can be multiplexed into their own MCHs, e.g. MCH1 for video service type, MCH2 for audio service type, etc.
Due to coding techniques, e.g. motion compensation, broadcasting of static video contents where object and background barely moves (e.g. news or music channel with still images) usually has relatively very low data rates. On the other hand, broadcasting of dynamic video contents, such as sports broadcasting, action movie, music videos without still images, usually has very high data rates. This difference of data size between videos may lead to the condition in which no data for a certain MBMS service will be transmitted for some scheduling periods.
When, for example, a sports channel and a news channel are transmitted simultaneously within an MBSFN area, as the news channel may have a considerably lower bit rate compared to the sports channel, the transmission of the news channel for a certain duration can be done with less scheduling periods.
It is therefore desirable that each MCH carries (dynamic) MCH scheduling information (MSI) for the services mapped to that MCH. Thus, a User Equipment (UE) only wakes up when the service(s) of its interest is (are) transmitted, while it can sleep during the transmission of other services or when no service is transmitted. It has been discussed in 3GPP standardization to transmit the MSI in the first Transport Block (TB) of a scheduling interval. The radio resource, e.g. a subframe in the context of Long Term Evolution (LTE), in which the MSI is transmitted, is therefore known implicitly from the start of the scheduling interval. A scheduling interval is typically 320 ms, but it may also be shorter or up to a few seconds in duration depending on the services' burstiness and on the limit of the delay that is introduced by the scheduling.
For example, the MSI indicates future scheduling of the MBMS services mapped to the respective MCH and indicates where no data for certain MBMS services will be transmitted for some scheduling periods. For this purpose, the MSI may contain information indicating by a number of scheduling period (like a counter), e.g. how many scheduling periods the UE has to wait for receiving certain MBMS services. Coding MSI of all MBMS services together and mapping the MSI for all MBMS services on the first TB increases efficiency. Further, the UE exactly knows where to wake up in the next scheduling interval(s). The UE only has to wake up extra for the subframe containing the scheduling block, even if it is not interested in the services carried in the first TB.
The MCH is configured according to the QoS requirement of the services it carries. The TB(s) containing the MSI, however, need to have a low BLER, because a UE that cannot decode the MSI at least faces the following problems. The UE that can not decode the MSI either: can not receive any TBs of the intended service in the considered scheduling interval, which reduces the QoS; or the UE has to read all TBs from the start of the scheduling interval up to the start of the TB segment of the intended service to be able to detect its start, which increases battery consumption in the UE.